Characteristics of a Good Software Requirements Specification for B.SC. IT SEM-VI
Characteristics of a Good Software Requirements Specification
A software requirements specification should be clear, concise, consistent and unambiguous. It must correctly specify all of the software requirements, but no more. However the software requirement specification should not describe any of the design or verification aspects, except where constrained by any of the stakeholders requirements.
Complete
For a software requirements specification to be complete, it must have the following properties:
-
Description of all major requirements relating to functionality, performance, design constraints and external interfaces.
-
Definition of the response of the software system to all reasonable situations.
-
Conformity to any software standards, detailing any sections which are not appropriate
-
Have full labelling and references of all tables and references, definitions of all terms and units of measure.
-
Be fully defined, if there are sections in the software requirements specification still to be defined, the software requirements specification is not complete
Consistent
A software requirement specification is consistent if none of the requirements conflict. There are a number of different types of confliction:
-
Multiple descriptors - This is where two or more words are used to reference the same item, i.e. where the term cue and prompt are used interchangeably.
-
Opposing physical requirements - This is where the description of real world objects clash, e.g. one requirement states that the warning indicator is orange, and another states that the indicator is red.
-
Opposing functional requirements - This is where functional characteristics conflict, e.g. perform function X after both A and B has occurred, or perform function X after A or B has occurred.
Traceable
A software requirement specification is traceable if both the origins and the references of the requirements are available. Traceability of the origin or a requirement can help understand who asked for the requirement and also what modifications have been made to the requirement to bring the requirement to its current state. Traceability of references are used to aid the modification of future documents by stating where a requirement has been referenced. By having foreword traceability, consistency can be more easily contained.
Unambiguous
As the Oxford English dictionary states the word unambiguous means [Hawkins ’88]: "not having two or more possible meanings". This means that each requirement can have one and only one interpretation. If it is unavoidable to use an ambiguous term in the requirements specification, then there should be clarification text describing the context of the term. One way of removing ambiguity is to use a formal requirements specification language. The advantage to using a formal language is the relative ease of detecting errors by using lexical syntactic analysers to detect ambiguity. The disadvantage of using a formal requirements specification language is the learning time and loss of understanding of the system by the client.
Verifiable
A software requirement specification is verifiable if all of the requirements contained within the specification are verifiable. A requirement is verifiable if there exists a finite cost-effective method by which a person or machine can check that the software product meets the requirement. Non-verifiable requirements include "The system should have a good user interface" or "the software must work well under most conditions" because the performance words of good, well and most are subjective and open to interpretation. If a method cannot be devised to determine whether the software meets a requirement, then the requirement should be removed or revised.